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Authors' abstract 



We investigate the use of the dot notation in the context of abstract types. The dot 
notation — that is, aj referring to the operation / provided by the abstraction a — is 
used by programming languages such as Modula-2 and CLU. We compare this notation 
with the Mitchell-Plotkin approach, which draws a parallel between type abstraction and 
(weak) existential quantification in constructive logic. The basic operations on existentials 
coming from logic give new insights about the meaning of type abstraction, but differ 
completely from the more familiar dot notation. In this paper, we formalize simple calculi 
equipped with the dot notation, and relate them to a more classical calculus a la Mitchell 
and Plotkin. This work provides some theoretical foundations for the dot notation, and 
suggests some useful extensions. 
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1 Introduction 



Type abstraction has emerged as one of the most important techniques for specifying and 
building large software systems [6, 4], since it provides fundamental typing support for 
modularization [14]. 

Abstract types (sometimes called opaque types) are therefore one of the necessary 
features of modern programming languages. However, for a long time their standing 
has been rather mysterious, and their type rules have been explained in ad-hoc and 
operational ways, making formal reasoning about abstract types difficult. For example, 
it is still commonly said that an opaque type is "different from any other type in the 
system when seen from outside the abstraction", or that a new abstract type is "created" 
whenever its description is evaluated. Such statements are both informal and arbitrary; 
clearly, a formal background is needed to define precisely what type abstraction means, 
derive sensible typechecking rules, and reason about programs using abstract types. 

In an attempt to fill this need, Mitchell and Plotkin [13] made an important connection 
between type abstraction and the second-order existential quantifiers of logic. They pro- 
posed that an abstraction — that is, an abstract type A, together with operations /, . . . 
whose types F, G, . . . normally involve A — should be viewed as an "existential" statement. 
That is, there should exist a concrete type representation of A and an implementation 
of the operations /,£,... such that /,#,... have the types F 1 G, . . ., respectively 1 . For 
instance, a package implementing complex numbers could be specified by the existential 
type shown in figure 1; two different implementations meeting this specification are shown 
in figure 2. An abstraction is therefore an assertion that adequate implementations exist; 
it provides a partial specification of such implementations. These existential statements 
might be false, in which case the specification of the abstract type should be seen as 
inconsistent. 

The approach of Mitchell and Plotkin showed for the first time that the type rules 
for abstract types could be described non-operationally, by looking at the well-known 
rules of constructive logic from the standpoint of programming. It also provided the 
necessary formal framework for proving fundamental properties of abstract types, such as 
representation independence [15, 11]. 

The connection between this approach to type abstraction and the notion of type 
abstraction found in several modern programming languages is however not complete. 
These languages use a dot notation, such as a./, to refer to an operation / provided 
by an abstraction a, or in other words, to the field named / of module a. The type 
theory approach provides an elimination construct that looks totally different, for the 
same purpose . We set out in this paper to investigate this difference in notation, explore 

x This type-theoretical notion of "abstract types", should not be confused with the many-sorted algebra 
approach. It is both weaker, since it does not involve equations (which can however be added in a type- 
theoretical logic), and also stronger, because of higher-order functions. 
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type Complex — 

3(7. make Real — ► Real — ► C 
re : C — ► Real 
im (7 — > Real 

md : (7 -+ <7 -+ (7 ... 



Figure 1: A specification of a complex arithmetic package 



val cartesian -complex : Complex = 
( C — Real x Real 
make = Xx : Real. Xy : Real, (x, y ) 
re = Ax : (7. f irst(x) 
zrn = Ax: C. second(x) 

mul = Ax : (7. Xy: C. (f irst(x). f irst(y) — second(x). second(y ), 

first(x). second(y) + second(x). f irst(y)) ) 
val polar -complex : Complex — 
( C = Real x Real 
make = Ax: Real. Ay: Real, (V^ 2 + 2/ 2 , arctan(y/x)) 
re = Ax: C. f irst(x). cos(second(x)) 
im = Ax: (7. f irst(x). sin(second(x)) 

mu/ = Ax : C. Xy : C. (f irst(x). f irst(y), second(x) + second(j/)) ) 
Figure 2: Two implementations of the complex arithmetic package 
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Xcomplex : Complex. 

open complex as (C, mk, re ) im, mul) in 

let square = Xx : C. mul x x in re(square(mk 2 3)) 

Figure 3: Using a package with the open notation 



Xcomplex : Complex. 

let square = Xx : complex. C. (complex .mul x x) in 
complex .re(square(complex .make 2 3)) 

Figure 4: Using a package with the dot notation 

also whether there is a difference in expressive power, and try to relate both notations, in 
the hope of filling one of the remaining gaps between the theory and the practice of type 
abstraction. 

The "logical" notation for abstraction uses a construct, which we call open here, 
corresponding to the logical rule for existential elimination. Namely, given a package p 
implementing an abstraction A, /,#,.. we can open the package p, bind its components 
to variables A f ,f\g\ . . and use such variables in a usage scope (following in): 

p:3A. f,g,... 

open p as A 1 , /', g\ . . . in . . . A! . . . /' . . . g' . . . 

The result of this expression is the result of the subexpression following in. Figure 3 shows 
how the complex arithmetic package above can be used with this notation. Additional 
examples using this notation can be found in Cardelli and Wegner [3]. 

It is easy to see why abstraction is enforced. Although A may be implemented in 
p as, say, Int, A f is a formal variable and cannot match any type except itself. This 
corresponds to the informal idea that abstract types are "different from any other type". 
There is also a crucial restriction that the type variable A' should not escape its scope: it 
must not appear free in the type of the result of open or in the types of global variables. 

Existential types provide a fully satisfactory theoretical solution to the problem of 
modelling abstract types. However, the open notation is very clumsy for programming 
purposes; if a package is opened twice, the two abstract type variables thus introduced 
will not match. Hence one must find a sufficiently large usage scope around which to 
place the open construct without violating the typing rules; MacQueen [9] points out that 
the required usage scope may be so large that most benefits of abstraction are lost. 

This difficulty motivated MacQueen to take a different approach to abstraction, using 
dependent types and general sums [9], His approach is adequate for modules (when they 
are not first-class values, as in Standard ML [8]), but not for abstract types, since packages 
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must now necessarily stop being first-class values to preserve typing decidability [12]. In 
addition, general sums do not ensure abstraction by themselves; hence, Standard ML 
provides a separate abstraction construct. 

Independently, programming languages providing facilities for type abstraction were 
developed, and most of them use a different notation. This programming notation uses a 
dot operator to select the components of a package, including selecting the abstract type 
when it is in a type context: 

p:3A. f,g>... 
...p.A...p.f...p.g... 

See figure 4 for a reformulation of the example above using this notation. 

This dot notation has proved very convenient for actual programming, especially for 
programming in the large. However, it does not lend itself to formalization as readily as 
the open notation. 

One difficulty with the dot notation is that the name A is bound and can be renamed: 
3A.B = 3A f .B{A*— A'}. Hence what does p. A really mean? Similarly, how are the names 
/,<7, ... handled? Programming languages seem to avoid this problem by rejecting a- 
conversion of existential variables. Here we circumvent the problem by using positions 
instead of names: p.Fst refers to the type component of an abstraction, and p.snd to the 
operation-set component. 

Apart from this difficulty, the main problem is that we no longer have a precise notion 
of the usage scope of a package. If p. A always matches (another occurrence of) p. A, why 
should it not match Int, or some other type? 

Moreover, p. A (or p.Fst) is now a type; hence we have introduced value expressions as 
subexpressions of type expressions. Should p. A match p'. A only if p = p'? Or if p and p' 
have the same normal form? Clearly some restriction should be imposed here to preserve 
typing decidability. 

Finally, are packages first-class values? In Modula-2 for instance, modules are not first- 
class values. In this paper, we wish to avoid this additional stratification, and assume 
that the p in p. A is a first-class value, so we can handle general abstract types and not 
just modules. Alternatively, we are assuming that our modules are first-class values and 
that multiple implementations of an interface can coexist [2]. But should we require p in 
p. A to be a simple identifier x, as in most programming languages, or a sequence x.y.z . . . 
? Or can we allow p to be an arbitrarily complex expression, provided that it has no 
side-effect, and that equality of two such expressions is decidable? 

If we had a translation between some flavor of dot notation and the open notation, we 
could avoid answering directly all such hard questions about the dot notation. We should 
not be afraid of losing expressiveness in the translation, since we believe existential types 
characterize the correct notion of abstraction. 
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The main question then that this paper addresses is under which circumstances is the 
dot notation equivalent to the open notation? 

First, in section 2, we introduce a simple calculus with the open notation, intended 
to serve as a reference point. We give typechecking rules, denotational semantics, and 
show the soundness of the type system. In section 3, the open elimination construct is 
replaced by a simplified dot notation, consisting of two projections, .Fst and .snd, that 
are syntactically restricted to apply to simple variables only. Then we prove that the 
calculus thus obtained is equivalent to the former one by translating one calculus into 
the other. The translations are reasonably faithful, since they preserve both typing and 
semantics. Finally, in section 4, we lift the restriction on .Fst and .snd, and allow them 
to operate on any term; it seems that not all terms of this calculus with generalized dot 
notation have equivalents in the original calculus with open; however, we characterize a 
large class of terms that can be encoded in the open notation, while retaining typing and 
semantics. 

2 A simple calculus with abstract types 

The calculus in this section is based upon the usual simply typed A-calculus, extended with 
constants and primitive operations as needed (such as integers, booleans and pairs, though 
we shall axiomatize only integers for simplicity.) To model type abstraction, we add 
existential quantification on types, and two term constructors: second-order dependent 
pairs and the open construct. These term constructors correspond to the introduction 
and elimination rules for existential quantification in constructive logic. 

2.1 Syntax 

In the following, X and Y range over a given countable set of type variable identifiers, A 
and B range over the class of types, similarly, x and y range over the set of term variable 
identifiers, and a, 6, c range over the class of terms. 

A ::= X | A -> B \ 3X. A 

a ::= x | Xx : A. b | b(a) | (X = A, b : B) \ open a as (X, y : B) in b 

The construct (X~A, b:B) builds a second-order dependent pair. This is basically a 
pair of a type A and a term b of type B\ however, b and B may depend on the binding 
X = A] that is, X may appear in b or in B, and is considered to be bound to A there. 
This binding is not visible outside of the pair; in particular, the type of the pair is simply 
3X. 5, without any mention of A. 
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The elimination construct open a as (X, y: B) in b evaluates a to a pair, binds X to 
its internal type and y to its value, and returns the value of b in this new environment. 
The variable X gets bound in B and 6; y is bound in b. 

For some purposes, we also consider the calculus above extended with integer con- 
stants: 

A ::= ... | Int 

a ::— . . . | 0 | succ(a) | case a of 0: 6, succ(x): c 

The pattern-matching construct case a of 0: 6, succ(x): c subsumes test for zero, the 
predecessor function, and the usual if . . . then . . . else construct; x is considered bound 
(to the predecessor of a) in c. 

As usual, expressions are identified up to a renaming of bound variables. 
2.2 Typechecking 

We specify the typing of terms of this calculus by a system of inference rules. The rules 
define the judgment "term a has type A under the assumptions E n , written E \- Q a : A. 

The assumptions are either "variable x has type A" or "identifier X is a valid type 
variable", hence the syntax of typing environments E is as follows: 

E\\=$\E,X\E,x:A. 

We write Dom(E) for the set of variables introduced in 2?, that is: 

Dom(9) = 0 Dom(E, X) = Dom(E) U {X} Dom(E, x:A) = Dom(E) U {x} 

However, we must put additional constraints on the environments, to ensure that type 
variables are introduced in the environment before being used in types. So we have to 
define two more judgments: "typing environment E is well- formed" , written ^ E ENV; 
and "type A is valid in environment written E h A TYPE, as follows. 

\l 0 ENV 

h; E ENV X $ Dom(E) Eh A TYPE x £ Dom(E) 

h E,X ENV b E,x:A ENV 

h E env h; E,X,E' env 

E h Int TYPE E, X, E' h X TYPE 



6 



E h A type Eh B type E } X hA type 



E h A -> B type BhJXA type 

We can now give the typechecking rules for terms. The first rules are exactly those of 
the simply typed A-calculus: 

h 0 E,z:A,E' ENV 
E,x:A,E'h*'A 
Eh A TYPE E,x:A\- 0 b : B 



E\- 0 \x;A.b: A^ B 
Ekb: A—> B EhaiA 



E h b(a) : B 
Typing rules for integers are straightforward: 



h E ENV E h a : Int 



E h 0 : Int Eh succ(a) : Int 

E h a : Int E h b : A E, x : Int h Q c : A 

E case a of 0: 6, succ(z): c : A 

A pair (A" = A, b: B) has type 3X. B if the claim 6 : B holds when considering the 
binding X = A in b and 5. The type A does not appear in the type of the pair; it is 
therefore hidden outside of the pair. 

Eh A type E h b{X^A} : B{X^A} 

Eh = b:B) : 3X. B 

If a has an existential type 3X. 5, then an open a as (X, y : B) in c construction has 
the same type as c. The term c is considered in an environment where the type variable 
X is defined and the term variable y has type 5. Inside c, the type X is a formal variable, 
which cannot match any type except itself. To ensure that X does not escape the scope 
of the open expression, we require that X is not free in the type C of the body c. This is 
ensured by requiring that C is a valid type in the original environment j£, in which X is 
unbound. 

E h a : 3X. B Eh a C TYPE E,X,y:Bhc.C 



E h open a as (X, y : B) in c : C 
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It is easy to see that E \- Q a : A implies E \~ Q A TYPE, which implies ^ E ENV in turn. 
This fact is used implicitly in the rules above. 

2.3 Evaluation 

The usual approach to evaluation would be to define reduction rules on the typed terms; 
following Mitchell and Plotkin [13], we could take, for instance: 

(Ax: A b)(a) -► 6{x<-a} 
open (X^ A, &:£) as <X, 2/:5) inc c {y<-b}{X<^A} 

plus some rules for constants. However, these rules do not identify terms that intuitively 
have exactly the same meaning, for instance 

open x as (V, z : Int) in succ(z) 

and 

succ(open x as (Y, z : Int) in z). 

Though the open a as . . . construct performs very little computation, it is not allowed to 
disappear until a is reduced to an explicit pair, which may never occur. This prevents a 
number of desirable reductions: (open x as (Y, z:Y) in Xu: Int. u)(0) is in normal form, 
while the corresponding untyped term (Xz. Xu, u)(x)(0) may be reduced. This turns out 
to be a major problem when trying to relate other calculi with this one, as we shall do 
later on, since the various typed reductions do not match, while the untyped reductions 
are the same. 

We could add other reduction rules to perform the desired identifications, but it is 
unclear whether the Church-Rosser and strong normalization properties would still hold. 

Instead, we choose to reduce the underlying untyped A-terms, obtained by erasing all 
type annotations. Pairs of a type and a term are identified with the term itself, hence 
the pairing operation simply disappears, and open becomes a simple binding of a term 
to a variable, similar to the let construct of ML. For simplicity, we express it by mere 
substitution of the variable by the term 

Erase 0 (x) 
Erase D (Xx : A. b) 
Erase 0 (b(a)) 
Erasz 0 ({X = A, b:B)) 
Erase 0 (open a as (X, y : A) in b) 

Erase o (0) 



= x 

= Ax. Erase 0 (b) 

— Eras e 0 (b)( Eras e 0 (a)) 
= Erase 0 (b) 

— Eras e 0 (b){y<— Erase 0 (a)} 
= 0 
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Erase 0 (succ(a)) = succ(Erase 0 (a)) 
Erase Q (ceise a of 0: 6, succ(z): c) = case Erase 0 (a) of 0: Erase 0 (b), 

succ(x): Erase 0 {c) 

After the erasing is performed, the untyped A-term thus obtained is reduced in the 
usual way [1]. However, when we add constants to this calculus, there is a possibility of 
a run-time type error during reduction; for instance, an integer could be applied as if it 
were a function. It remains to show that this cannot occur if the initial term is well-typed. 

To be more precise, we shall use a denotational semantics for the untyped A-calculus. 
Following MacQueen, Plotkin and Sethi [10], we choose a domain V isomorphic to N_l + 
(V — ► V) + {wrong} x . Then to each untyped term m, considered in an environment />, 
we associate a meaning that is a value \m\ p of the "universe" V; meaningless terms, that 
is terms whose evaluation leads to a type error, are mapped to wrong. The environment 
p is a partial mapping from term variables to values of V. 

i x ip — p( x ) if defined, wrong otherwise 
[Ax.mjp — v i ► [m],^] 

[m(n)] p = if [mj, is in V^V then ([m] p )(|[n],) else wrong 
[0], = 0 

[succ(m)] p = if [m] p G N_l then |m] p + 1 else wrong 
[case m of 0: n, succ(x): pj p = if [m] p = 0 then [n], 

if lmj p = t + 1 then [p],^ 
else wrong 

We can now state the soundness of the typing rules: 

Proposition 1 For all terms a and types A,if$\- 0 a:A, then Erase G (a) does not denote 
wrong ; that is lErase 0 (a)\$ ^ wrong. 

To prove this proposition, we shall first give a meaning to type expressions as well. 
Following the ideal model of types [10], we interpret type expressions as ideals of V, as 
follows: 

[Intj, = N x 
\X\ P — p(X) if defined, 0 otherwise 

= {/€ V -> V | V«e[A]„ /(*)€[*],} 

13X.A} P = □ lAj p[x ^ w] 

W ideal 

wronggvr 

where in addition p maps type variables to ideals of V. Notice that if wrong is not in 
p(X) for any X, then wrong £ [^4]^ for all types A. The soundness of typing then follows 
easily from the following claim, which is proved in [10]: 
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Proposition 2 Assume E \- 0 a : A. Let p be a mapping compatible with E; that is } for 
all type variables X 6 Dom(E), the ideal p(X) does not contain wrong, and for all term 
variables x £ Dom(E), the denotation p(x) belongs to lE(x)} p . Then \Erase 0 {a)\ p G [A} p . 

Apart from confirming that the type rules are sensible, this soundness result is a 
clue that indeed data abstraction is ensured in this calculus. Data abstraction is usually 
characterized by representation independence properties. These properties formalize the 
intuition that two "equivalent" implementations of an abstract type are not distinguish- 
able; that is, the observed behavior of a program using one or the other is the same. 
Soundness of typing is a (weak) representation independence property, where two terms 
are equivalent when they have the same type, and observed behavior is the absence of 
run-time type errors. Stronger representation independence properties hold for this cal- 
culus; for instance, Mitchell [11] shows (for a superset of the calculus in this section) that 
if two implementations of an abstraction are related by a logical relation, then one can 
be substituted for the other in any closed term without modifying its meaning. 

3 A calculus with the dot notation 

We now formalize a calculus based on the dot notation. This is a A-calculus with second- 
order dependent products, differing from the one in the previous section only in the way 
of splitting existentials: instead of a single open construct, it provides two constructs: 
one for accessing the value part of the pair, written z.snd; and one to get a witness of the 
abstracted type, written x.Fst. As this is intended to model the "qualified identifiers" of 
Modula-2 [16] and the "abstract tuples" of Quest [2], we shall in this section restrict .Fst 
and .snd to operate on term variables only. 

3.1 Syntax 

We keep the same notational conventions: X and Y are type variables, A and B are types, 
x and y are term variables, and a and b are terms. 

A :: = X | A^ B \ 3X. A \ x.Fst 
a x | Xx:A.b | 6(a) | (X = A, b:B) \ x.snd 

As previously, we can extend this dot calculus with integer constants: 

A ::=.... | Int 

a :~ ... | 0 | succ(a) | case a of 0: 6, succ(x): c 
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3.2 Typechecking 

As in the previous section, we have to define the judgment E h a : A, as well as two 
auxiliary judgments h E ENV and E h A TYPE. 

Type environments have exactly the same structure, and are well-formed under the 
same conditions : 

h 0 ENV 

hi E env X £ Dom(E) E h A TYPE x£Dom(E) 

hE,XENV hE,x:AEKV 

For type validity, we have to add one rule for the new construction z.Fst, stating that 
it is a valid type whenever x is shown to have an existential type. 

h E, X, E' env E, X b A type 

E, X,E'hX type E h 3X. A type 

E h A type E h B type E h- d x : 3X. A 

E\- t A-*B TYPE E rj z.Fst TYPE 

For typechecking of terms, we drop the open rule and keep the other four rules. As 
term variables may now appear in a type expression, they must be prevented from escaping 
their scope. Hence, the rule for functions Xx : A. b states that x is not free in the type B 
of the body b. As in section 2.2, this is ensured by requiring that B is a valid type in the 
original environment E, which does not define x. 

h d E,x:A,E' ENV 
E,x:A,E'h x : A 

Eh A TYPE E h B TYPE E,x:Ahb:B 
E \~ d >ix:A.b : A —> B 
E \~ d b : A -+ B E\- d a:A 
E h b(a) : B 
Eh A TYPE E h b{X^A} : B{X^A} 
E h {X = A, b:B) : 3X. B 
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The new construct x.snd is well-typed provided that x has an existential type 3X. A] 
its type is A, where the abstracted type X is substituted by its witness x.Fst. 

E h x : 3X. A 
E h x.snd : A{X*-x.?st} 

3.3 Evaluation 

As in section 2.3, we do not reduce typed terms directly, but rather strip all type informa- 
tion first and then evaluate the untyped A-term thus obtained. This stripping is defined 
on terms with dot in the same vein as in section 2.3, with the additional case: 

Erastd{x. snd) = x 

Instead of directly investigating this calculus — proving the soundness of the type 
system, for instance — we shall first try to relate it to the open calculus. Indeed, we 
are going to provide translations from terms of one calculus into the other calculus. The 
translations are reasonably faithful in that they preserve typing and semantics. Most 
interesting properties of the open calculus can then be effortlessly shown to hold in the 
dot calculus as well. 

3.4 Encoding the dot calculus in the open calculus 

The idea behind both translations is that, in the body of an open x as (Y, z : A) in b 
expression, Y and z seem to have the same meaning as x.Fst and x.snd, respectively. 
This remark suggests the following strategy to transform a program with dot into one 
with open: insert some open x as {Y, z : A) in ... for each variable x used in a x.Fst or 
x.snd construct, and use Y and z instead of x.Fst and x.snd. In other words: 

6[x.Fst, x.snd] i — > open x as (Y, z: A) in b[Y, z) 

For instance, this would allow the following translation: 

\x\3X.X x X -> Int. (second(x.snd))(first(x.snd)) i — > 

Ax : 3X. X x X Int. (open x as (Y, z : Y x Y -> Int) in second(z)) 

(open x as (7, z : Y x Y — ► Int) in f irst(z)) 

and this is obviously wrong, since the scoping constraint of open is not respected. (Y 
appears free in the types of the results.) So, this scheme must be restricted to the cases 
where x.Fst does not appear in the type of 6[x.Fst, x.snd]. Presumably, this may be 
achieved by taking a subexpression b large enough to enclose all uses of x.Fst and x.snd; 
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Az:3X. ComplexWRT(X). 


.snd)(3)(2))) 


second(z.snd)^(A2 : z.Fst. f ourth(x.snd)(z)(z))(f irst(x 


In the open calculus: 




\x:3X. ComplexWRT(X). 




open x as (X, y: ComplexWRT(X)) in 




second(y)((Az:X. f ourth(y)(z)(z))(f irst(y)(3)(2))) 





Figure 5: Translation from the dot calculus to the open calculus 



indeed, the body of the A-abstraction binding x will do, since the typing rule for A prevents 
x (and, hence, z.Fst) from being free in the type of the body. 
Therefore, the following translation scheme seems sensible: 

Ax : 3X. A b i — ► Xx : 3X. A. open x as (X, y : A) in b{x.Fst<— A r }{a:.snd<— y} 

For instance, if we express the complex arithmetic example (figures 3 and 4) in the open 
calculus and in the dot calculus (see figure 5), the translation outlined above actually 
transforms the first program into the second one. This scheme works for closed terms, 
but we shall soon describe a translation for open terms as well. 

Now, we would like to show that a well-typed term translates to a well-typed term. 
To allow for easy induction on derivations, we need to translate not only terms, but also 
whole judgments. Hence, we first reformulate the translation in a more general (and more 
controlled) way. 

3.4.1 Formal definition of the translation 

Let a 0 be a closed, well-typed term of the dot calculus. To avoid name clashes, we rename 
the identifiers appearing in a 0 so that none gets bound more than once. 

Let V be the set of term variables x such that x.Fst or x.snd appear in a,Q. Given 
the typechecking rules for projections, each x £ V has an existential type; we write it as 
3T X . A x , after renaming if necessary 2 . 

2 Due to the typing rule for pairs, this type may differ from the type declared for x by the abstraction 
binding it, as in (X = 3Y. Int, Ax : X. x.snd: X — ► Int). The type 3T X . A x we associate with x is the 
"true" type of x; that is, the type given to it in the derivation of ao : Aq (this derivation is unique, given 
the typing rules), or alternatively the type declared for x, where all bindings such as A' = 31". Int above 
have been performed. 
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To each x £ V, we associate a term variable v x that does not appear in a 0 . 
For each subterm a of ao, we define its translation [a\ &s follows: 

[x\ — x 
[x.sndj = v x 

. open x as (T x , v x : [A x \ ) in [b\ if x G "P 
[Ax : A 6J = Ax : [AJ . [b\ if x £ 7> 
[b(a)\ = L*J(L*J) 
L(X = A,6:S)J = (X=|AJ, |&J:L*J) 

This is basically the transformation outlined above, with substitutions delayed, and per- 
formed only when necessary: we insert an open x as . . . only when x £ V\ that is, when 
x.Fst or ar.snd are actually used. 

In the same vein, types translate as follows: 

\_X\ = X 
[z.FstJ = T x 
[A^B\ = [A\^[B\ 
[3X.A\ = 3X. [A\ 

To translate environments, the only case that needs special treatment is the intro- 
duction of a variable x belonging to V. In the derivation, this case corresponds to the 
typechecking of the body b of a function Ax : A. b. After translation, b will be preceded 
by an open x as (T x , v x : [A x \] in so we must typecheck the translation of b in an 
environment where T x and v x are defined. Hence the translation of E, x : A introduces T x 
and v x : [A x \ in addition to x : [A\ . 

L0J - 0 
[E,x\ = [e\,x 

[E,x:A\ = [E\ } x:[A\ } T x ,v x :[A x \ifxeV 
[E,x:A\ = [El.xi^iix^V 

3.4.2 Preservation of typing 

We are now able to translate any judgment componentwise, and in particular 0 ^ a 0 : A 0 . 
To prove that the translation preserves typing, it remains to show that its translation 
0 h [ a o\ '• \_A 0 \ can be derived in the open calculus. 

Proposition 3 Let a 0 be a closed, well-typed term of the dot calculus. Let [ J be the 
associated translation function. Let D be the derivation o/ 0 \z ao • Ao. 
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IfhE ENV is proved in D } then ^ [^J ENV - 

If E\- d A TYPE is proved in D, then [E\ k [A\ TYPE. 

If E \~ d a \ A is proved in D, then [E\ \~ Q [a\ : [A\ . 

of: By induction on the three derivations, starting with the one of E \- d a : A. 

For value variables: we have the following derivation 

b E u x; A,E 2 ENV 
E u x: A, E 2 h x : A 

By induction, we have a derivation of \~ D [E u x: A,E 2 \ ENV. By definition of the 
translation, [E u x : A, E 2 \ has clearly the form E[,x : [A\ y E l 2 . Hence the desired 
result [E u x\A,E 2 \ \- Q x : [A\ follows. 

For value access in a pair: from the original derivation 

hE u x:3T x . A xy E 2 ENV 
E x ,x:3T x . A X ,E 2 hi x : 3T X . A x 
E u x:3T x . A X ,E 2 b x.snd : A x {T x ^x.Fst} 

we get by induction a derivation of k \_E u x: 3T X . A xy E 2 \ ENV. As z.snd appears 
in the derivation above, x belongs to V. Therefore, [Ei, x : 3T X . A X) E 2 \ introduces 
the variable v x with type [^J . Hence [E\ \~ Q v x : [A x \ , which implies the expected 
result 

[E\ h [x.sndj : [A{X<-x.F*t}\ 

since, as [z.FstJ = T xy 

[A{T 9 <-x.¥st}\ - [A\ 

For abstraction: 

E \- d A TYPE EY- d B TYPE E,x:A\~ d b:B 
E \- d Xx\ A.b \ A ^ B 
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If x V, by induction we have proofs of 

[E\ h [A\ TYPE 
[E,x:A\h[b\:[B\ 

that is 

[E\,x:[A\k[b\:[B\ 

hence 

[E\ h Xx : [A\ . [bj : [Aj [B\ 
which is the desired result. 

If x £ V, then A = 3T X . A x , and the same steps lead to: 

[E\ h 3T X . [A x \ type 

[E\ h [B\ TYPE 
[E\,x:3T x . [A x \,T x ,v x :[A x \ h„ [b\ : [5J 
so we have the following derivation: 

[E\,x:3T x . [A x ] hx:3T x . [A x ] 
[E\ h [B\ TYPE 
[E\,x:3T x . [A x \,T x ,v t :[A x \ h [b\ : [B\ 

[E\,x: 3T X . [A x \ h open x as (T x , v x : [A x \ ) in [b\ : [B\ 
[E\ h„ 3T X . [A x \ type 

[E\ h Xx:3T x . [A x \. open* as u*: |A«J) in [6J : 3T X . [A X J - [#J 

that leads to the desired result: 

[E\ h [Xx:A.b\ : [A->B\ 

• For application: obvious by induction hypothesis. 

• For pair construction: from 

Eh A type E h b{X^A} : B{X*-A} 
Eh{X = A,b:B):3X.B 
we get by induction hypothesis proofs of 

[E\ h [A\ type [E\ h [b{X*-A}\ : [B{X^-A}\ 
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To conclude that \_E\ h {X = [A\ , [b\ :[B\): 3X. [B\ , it suffices to show that 

[b{X^A}\ = [b\{X^[A\} 
[B{X*-A}\ = [B\{X<-[A\} 

The proof is by induction on b and B. We give the non-trivial case: b = Ax :C. d 
with x e V. 

[b{X*-A}\ = Xx : [C{X<-A}\ . open x as (T x , v x : [A x \ ) in [d{X<-A}\ 

= Xx : [C\ {X^ [A\}. open x as (T Si v x : [A, J } in [d\ {X^- [A\ } 

by induction hypothesis. The type variable X is not free in A x (indeed, by definition 
of T x and A X} the type 3T X .A X is C where some type variables have been substituted, 
and especially X has been substituted by A). Therefore X is not free in [A x \ either. 
Hence the desired result: 

[b{X^A}\ = {Xx:[C\.openx^s(T x ,v x :[A x \)in[d\){X^[A\} 
= [b\[X^[A\} 

We turn now to the E \~ d A TYPE judgment. All cases are straightforward, except 
maybe the one for x.Fst; but then the original derivation is: 



h jBi,x:3T x . A x ,E 2 ENV 
E u x:3T x . A XJ E 2 hx:3T x .A x 
E u x:3T x . A X ,E 2 h x.Fst TYPE 



The translation of E\ } x : 3T X . A XJ E 2 introduces the type variable T x , and it is a well- 
formed environment, so [E u x:3T x . A X} E 2 \ \~ 0 T x TYPE holds, which is the desired result 
since [z-FstJ = T x . 

Similarly, for the E ENV judgment, the only interesting case is the introduction of 
an x belonging to V. By definition of T x and A xy the type given to x must be 3T X . A x . 

E,T X \- d A x TYPE 

E h 3T X . A x TYPE x g Dom(E) 
b E,x:3T x . A x ENV 



17 



By induction, we have a proof of [E\, T x ^ [^4 X J TYPE, hence the following derivation: 
[E\,T s h [A x \ TYPE 

L^J h 3T X . [A x \ TYPE x <£ Dom([E\) 

h [E\,x:3T x . [A x \ env T x ^Dom{[E\ 1 x:3T x . [A x \) 

h [E\,x:3T x . [A X \,T X ENV 

We can substitute this for the proof of k [E\,T X ENV in the derivation of [^J,^ \~ 0 
[A x \ TYPE, thereby obtaining a proof of [E\,x:3T x . [A X \,T X h [A x \ TYPE. Hence: 

[E\ , s : 3T X . [A x \ , T x h [A x \ TYPE v x £ Dom( [E\ 9 x: 3T X . [A x \ , T x ) 

h [E\,x:3T x . [A x \,T XJ v x :[A x \ ENV 

□ 

3,4.3 Preservation of semantics 

As the translation respects the structure of functions and applications, a closed term of 
the dot calculus and its translation in the open calculus have exactly the same underlying 
untyped terms. More precisely, we have: 

Proposition 4 For all subterms a of a 0} 

Erase 0 ([a\){v x <r-x for all x 6 V} = Erase d (a). 

Hence Erase Q ( |_a 0 J ) = Erased(a 0 ). 

Proof: By induction on a. We give the main cases: 

• if a = x.snd, Erase d (a) = x and Erase 0 ([a\) = v x . 

• if a ~ \x:A.b and x G V, then 

Erase 0 ( [a\ ) - Erase Q (Xx : [A\ . open x as (T x , v x : [A x \ ) in [b\ ) 
= Ax. (Erase 0 ([b\){v x <— x}) 

hence, by induction hypothesis, 

Erase Q ( [a\ ){v y <— y for all y G V} = 

\x. (Erase 0 ([b\){v x ^-x}{v y ^y for all y £ V \ {x}}) = 
\x. Erased [b\ ) 

which is the expected result. 



18 



The remaining cases are obvious. 



□ 



Using the last two propositions, we can show the soundness of the type system of 
the dot calculus, extended with integer constants as mentioned in section 3.1. (The 
translation function is extended to the integer constructs in the trivial way, by translating 
their components recursively; it is easy to see that propositions 3 and 4 still hold.) 

Corollary 1 7/0 ^ a 0 : A 0 , then Erased(a 0 ) does not denote wrong. 

Proof: The translation [a 0 \ is a well-typed closed term of the open calculus. Hence, by 
proposition 1, \Erase 0 ( [a 0 \ )Jo ^ wrong, which is the desired result, since Erase Q ( |_a 0 J ) = 
Erase d (a 0 ). □ 



3.5 Encoding the open calculus in the dot calculus 

The reverse translation is much less informative, but would confirm the intuition that the 
dot calculus is no less powerful than the open calculus, so we shall sketch it quickly. 
The basic idea is to replace every open a as (X, y : A) in b by 

(Xz : 3X. A. b{X+-zJst,y^z.snd})(a) 

for some unused term variable 2. In contrast with the previous translation, any type 
of the open calculus is also a type of the dot calculus, and this also holds for well- 
formed environments. Hence we just have to provide a translation for terms, which is 
straightforward: 



\x] — x 

\Xx:A. b] = Xx:A.\b] 

\b(a)] = \b](\a)) 

\(X = A,b:B)] = (X = A, \b]:B) 

[openaas(X, y:A)inb\ = {Xz:{3X. A). \b}{X^z.Yst,y^z.sTi&}){\a~\) 

where z is not free in open a as (X, y : A) in b 



We must check that, in the last rule, the substitution of y by z.snd can be performed, 
since in z.Fst or z.snd, x cannot be substituted by any term but another variable without 
producing a syntactically incorrect term such as a(6).Fst. Happily, by definition of the 
translation, if y.Fst or T/.snd appears in [6], then y is bound by a A, and hence will not 
have to be substituted. 

As [ J , the function f" ] preserves typing and semantics: 
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Proposition 5 If E \- 0 a : A, then £ h d [a] : A. 

Proof: by induction on the original derivation. The only interesting case is the trans- 
lation of an open construct: 

Eha:3X.A EhB TYPE E,X,y:At- 0 b : B 
E open a as (X, y : A) in b : B 

By induction, it follows that E \~ d \a] : 3X. A and E,X,y:A\~ d \b] : B. By induction on 
the proof of the latter, we get a derivation of 

E,z:3X. A \~ d \b~\ {X<-z.Fst , y<-z.snd} : B{X*-z.Fst} 

As X is not free in £, we have B{X+— z.Fst} = B. Finally, from the proof of E V d \a] : 
3X. A, we can prove that E h 3X. A TYPE. Putting all together, we get: 

E b 3X. A TYPE 
E h B TYPE 
E,z:3X. A [6] {X*-z.Fst, 7/<-z.snd} : 5 

£ H d Az : 3X. A. [6] {Xw.Fst, y+-z.snd} :3X.A-+B E h \a] : 3X. A 

E \~ d (Xz:3X. A. [fc]{X^z.Fst,^z.snd})([al) : 5 

This is the expected result, □ 

Proposition 6 For any term a of the open calculus, Erased( [a] ) ^-reduces to Erase Q (a). 
Proof: similar to the proof of proposition 4. □ 

4 A more powerful calculus with dot 

In this section, we simply lift the restriction that only a value variable may be the argument 
of a .Fst or .snd construction, and allow instead any term, provided it has an existential 
type. 

Regarding the formalism, this is a very natural generalization of the previous dot 
calculus, reminiscent of the second-order general sums (also called strong sums) of type 
theory [7, 5]. 

From the point of view of programming languages, this extension, in its full generality, 
does not seem to model any real situation, especially since .Fst now embeds the whole 
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class of values into the class of types; this means that the dividing line between types and 
values begins to blur dangerously. 

However, we may feel the need for a calculus less restrictive than the dot calculus of 
the previous section. For instance, to deal with nested modules, it seems natural to have 
not only one-level access in modules, such as module .Type, but also access through paths 
of arbitrary length, such as module . submodule . data. To formalize this, the argument of 
a .Fst or .snd must be allowed to be a path, where a path is a term variable followed by 
an arbitrary number of .snd. 

We could study this first extension of the dot calculus in the same way as for the 
dot calculus, by finding a translation to the open calculus and proving that it is faithful. 
However, other similar extensions may come to mind, and the same work would have to 
be done for each. Therefore, it seems easier to study the most general extension of all, 
where any term can appear to the left of a .Fst or .snd construct. 

4.1 Typing 

The typing rules are exactly those of the simple dot calculus, with the obvious general- 
ization for the projections: 

Eh a a:3X.A E \~ 8 a : 3X. A 

E h s a.Fst TYPE E \~ t a. snd : a. Fst} 

It may be tempting to identify certain type expressions of this calculus, for instance 
(X = A, b: J5).Fst and A, and to use this notion of type equivalence for typechecking, 
instead of for strict equality. This amounts to adding the following rule: 

Eh a: A A <-> B 
E\- s a:B 

At first, we choose to disallow the latter rule and require syntactic equality for two types 
to be compatible; we shall come back to this issue later on. 

4.2 Evaluation 

As usual, we strip all type information before reducing. The .snd operation becomes 
identity on A-terms: 

Erase 3 (a. snd) = Erase a (a) 

As for the simple calculus with dot, we shall not investigate this calculus directly, but 
try to relate it to the open calculus first. 
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4.3 Relation to the open calculus 

When we try to encode this calculus into the open calculus, we find terms which apparently 
have no equivalents in the open calculus. For instance, assume a : A and consider the 
following term: 

(X = A, (Y = X, a:Y).snd:(Y = X, a:r).Fst) 
To express it in the open calculus, we have to insert an open {Y = X, a: Y) as . . . at some 
point, and since X is free in the pair, the only literal translation is: 

(X = A, open(Y = X, a:Y) as (Z, z:Z) inz:Z) 

but then Z escapes the scope of the open construct. (See later for a similar term but with 
no trivial redexes.) 

To try to find an equivalent term in the open calculus, the general strategy is the same 
as in section 3.4: replace subterms such as 6[a.Fst, a.snd] by open a as{X, y:A)in b[X,y] 7 
with the additional constraints that a. Fst should not appear in the type of 6[a.Fst , a.snd], 
and that b must not bind any of the free variables of a. However, the previous example 
shows that sometimes both constraints cannot be satisfied, especially when type variables 
are free in a. 

If a has no free type variables, the transformation might work: let b be the body of the 
smallest abstraction Xx:A.b enclosing all uses of a.Fst and a.snd. Either a.Fst does not 
appear in the type B of 6, in which case it is possible to insert an open a as . . . there, or 
a.Fst is part of B. But in the latter case, x $ FV(B), hence x is not free in a. Therefore, 
we can "lift" a out of 6, consider the next enclosing A, and iterate. 

We are now going to formalize this argument in the same way as in the previous section 
by providing translations for terms, types, and environments. 

4.3.1 A translation function 

Let a 0 be a closed, well-typed term, renamed so that each variable gets bound once at 
most, and let D be the derivation of 0 r; a 0 : A 0 . We write V for the set of subterms a of 
ao such that a.Fst or a.snd appears in D. 

From now on, we shall suppose that the following condition holds: 

(C) For all a £ V, there are no type variables free in a. 

For instance, it was not the case in the previous example, where V = {(Y = X J a:Y)}. 

For each a £ V, the term a has no free type variables, therefore D derives a type 
for a 3 ; this type is an existential type (given the typechecking rules for .Fst and .snd), 

3 Hypothesis (C) is crucial here, since in general, it is not true that any subterm of a 0 is given a type 
in D, because of the typing rule for pairs {X = A 1 b:B) i which requires that b{X<-A} has a type, but not 
necessarily b itself. For instance, Xx:X. succ(x) has no type by itself, though (X = Int, \x:X. succ(a;): 
X — * Int) is well-typed. 
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and we write 3T a . A a for it (after renaming of variables if necessary). Furthermore, we 
associate with a a value variable v a unused in a 0 . 

Now we have to decide, for all a e V, where to insert an open a as ... Let a G V. 
We consider the smallest subexpression b of a 0 binding all free variables of a. Since no 
variables are bound twice, such a b exists, and it contains all occurences of a.Fst and 
a.snd. If a is closed, it is a 0 . Otherwise, as there are no type variables free in a, it is 
the body of a A-abstraction Ax : A. b. We shall consider only the latter case, since we 
can assume without loss of generality that a 0 itself is a A-abstraction. We say that the 
variable x bound by this abstraction is the first free variable of a. 

For all term variables x, we write F(x) for the sequence of all a G V such that x is the 
first free variable of a. The translation of terms consists mainly in inserting, before the 
body b of any function Ax : A, 6, an open [a] as (T ai v a : [^ a J) in . . . for each a £ F{x). 
However, we must take care of the order of insertion, to avoid using a T a or v a before 
it is defined. More precisely, if a and a 1 belong to T(x) and a is a subexpression of a', 
then open a as . . . must precede open a 1 as . . . Therefore, we enumerate the sequence 
— ai, . . . , a n in topological order, that is if a; is a subexpression of aj, then i < j. 

\_x\ — x 
[a.sndj — v a 

[Xx:A.b\ - AxiLAJ.openLaaJ as(r ai ,t; ai :LA 0l J)in ... 

open [a n J as {T* n} v an : [A an \) in [b\ 
if F(x) = a ly ...,a n 
[b(a)\ = [b\([a\) 
l(X = A,b:B)\ = (X=[A\ 9 [b\:[B\) 

Notice that the third rule remains valid if T(x) = 0, and means [Xx \A.b\ = Ax : [A\ . [b\ 
in this case. The translation of types is the same as for the original dot calculus: 

[X\ = X 
[a.FstJ = T a 
[A B\ = [A\^[B\ 
[3X. A\ = 3X. [A\ 

As for the original dot calculus, we must synchronize the translation of environments with 
the translation of terms. Adding x : A to E means that we are about to typecheck the 
body b of Xx : A. b. After translation, b will be preceded by open a as (T a , v a : [A a \ ) in 
for each a £ T{x). So, the translation of E, x : A must define T a and v a : [A a \ for each 
a G F(x). 

L0J = 0 
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[E,X\ = \E\,X 

if F(x) - ai s ...,a n 

Condition (C) ensures that all a 6 P are translated, and that no T a or v a is free in 
[aoj , since the open a as (!T a , t; a : [A a \ } in ... encloses all uses of T a and v a . 

4.3.2 Preservation of typing 

Proposition 7 // one o/ the judgments \~ 8 E ENV, E \~ a A TYPE, or E \~ M a : A is a step 
of the derivation D } then we can prove h a [E\ ENV, [E\ b [A\ TYPE, or [E\ ^ [ a J : LAI 
respectively. 

Proof: the proof is a straightforward generalization of the proof given for proposition 3. 
We proceed by induction on the derivation of the judgment. Here are the interesting 
cases: 

• For value access in a pair: the original derivation is 

Eh a: 3T a . A a 
E k a.snd: ,4 a {r a ^a.Fst} 

so a 6 V and E binds all free variables of a, including its first free variable. Hence, 
[E\ introduces v a with the type [A a \ . By induction, we get a proof of [E\ h [a\ : 
3T a . [A a \ , from which we can extract a proof of h [E\ ENV. Hence, [E\ ^ v a : [A a \ , 
which is the expected result, since [a.sndj = v a and obviously, 

LA Q {T Q ^a.Fst}J = [A a \ 

• For A-abstraction: 

Eh. A TYPE Eh B TYPE E,x:Ah,b:B 
Eh Xx.A.b: A B 

Let a.i, . . . , a n be J-{x). For all i, since is a subterm of b and since there are no 
type variables free in a<, the derivation of E, x : A h, b : B contains a derivation of 
E ai h, a.i : 3T ai . A ai for some environment E ai . So, by induction, we get proofs of 

[Ej t- a [A\ TYPE 
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[E\ h [B\ TYPE 

S n h [b\ : [B\ 
[E ai \ k [a { \ : 3T ai . [A ai \ 
where E; = [E\ , x : [AJ , T ai , t; ai : [ ^ J,...,T ai , v aj : [A a J for all 0 < j < n. 

As a{ is a subexpression of 6, it is easy to see that S n and [E ai \ bind the free variables 
of ^ to the same types. Furthermore, as ^(x) is enumerated in topological order, 
for all j > i, the terms aj.Fst and a^.snd do not appear in a,*, therefore T a . and v aj 
are not free in [a»J. Hence, and [E ai \ bind the free variables of a { to the same 
types. So, from the derivation of 

\_E ax \ h [aij : 3T a , L^„ f J 

we can build a proof of 

Ei-x h D [a,j : 3T ai . [A a ,j 

Since Si is an extension of [E\ , from the proof of [E\ ^ [B\ TYPE, we get a proof 
of E; k [B\ TYPE. Hence the desired result: 

S n h [b\ : [B\ 
S n _! ^ [B\ TYPE 
Sn-i b LanJ : 3T an . [A an \ 

£„_! h open [a n J as <T anJ v an : IAJ ) in \b\ : [B\ 
S n _ 2 h [B\ TYPE 

S n _ 2 h„ L^-iJ -.bt^. LA an _J 



L^J , x : [AJ h 0 open as (T ai , v ai : |_4.,J ) in . . . [6J : [^J 

[E\ h \_A\ TYPE 

[E\ h \_Xx:A.b\ : [A-*B\ 

• For the introduction of a value variable in an environment: 

E \~ 3 A TYPE x £ Dom(A) 
\- s E,x:A ENV 

Let ai, . . . , a n be !F{x). If n = 0, we get by induction a proof of |_£J k [A\ TYPE, 
hence the desired result [-^J > x : L^J ENV - 
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Otherwise, by the same reasoning as in the case of A-abstraction, we have a proof 
of: 

[E\,x:lA\,T ai ,v ai :[A ai \,...,T an _ l1 v an _ 1 :[A^_ l \ h [a n \ : 3T an . [A an \ 
from which we can extract a derivation of: 

[Elx:[A\,T ai ,v ai :[A ai \,. . . ^^^-.[A^ h 0 3T an . [A ttn J TYPE 
whose penultimate step is: 

[E\,x: [A\ , T ai , v ai : [A ai \ T an _, , v an _ x : [A^.J , T an h [A a „J TYPE 
Hence the desired result: 

h[E\ 9 x: [A\ , r oi , v ai : [A ai J , . . . , T flm , v an : [A an \ ENV 

The remaining cases are easy, □ 
4.3.3 Preservation of semantics 

As in the previous section, this translation does not modify the meaning of the program: 
Proposition 8 For all subterms a of do, 

Erase 0 ([a\){v^Erase 0 ([b\) for all b £ V} — Erase s (a). 
Hence Erase Q { [clq\ ) — Erase s (ao). 

Proof: Same proof as for proposition 4. □ 

As a consequence of propositions 7 and 8, no closed term for which condition (C) holds 
can evaluate to wrong. Indeed, this is true even if condition (C) does not hold, since the 
type system of the generalized dot notation is sound, as can be proved directly along the 
lines of section 2.3. However, it is not clear whether the generalized dot notation ensures 
as strong an abstraction as the original open construct. Informally, we may fear that it 
is not the case, since, for instance, implementations of abstractions can be fully visible in 
types: 

(X = Int, 0:X).snd : (X = Int, 0:X).Fst 
thus publicizing that X = Int. 
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4.4 Type equivalence modulo reduction 

As mentioned previously, we may add the following rule: 

Eh a: A A <-> B 

Eha:B (1) 
where the equivalence relation is the congruence generated by the axioms: 

(X = A, b:B)Jst <r+ A 
(X = A, b:B).snd ~ b{X<-A} 
(Ax : A. b)(a) <-> b{x<-a} 

Even if rule 1 uses only equivalence between types, we need to define also equivalence 
between terms, because a.Fst is equivalent to fc.Fst if a is equivalent to 6. 

This rule leads to a weaker notion of abstraction, where succ((X — Int, 0 : X).snd) 
typechecks, for instance. MacQueen [9] argues that this additional flexibility is desirable 
for a programming language, in order to be able to express complex dependencies between 
modules. However, the DL language he proposes is stratified, and this is not by chance, 
since an unstratified system like ours equipped with rule 1 is inconsistent, as it is possible 
to encode a calculus with a type of all types in it [12]. 

Even if we add some stratification, allowing reduction during typechecking, as above, 
does not seem to modify drastically the previous results. Admittedly, the counterexample 
we gave to show that some terms have no equivalent in the open calculus, 

(X = A, {Y = X, a:Y).snd:{Y = X, a:Y) Jst) t 

now fails, since it reduces to (X = A, a : X). But we can work out more complicated 
examples, without any redex, that exhibit the same pathology, for instance: 

\f:(3X. A) — (3Y.B). 

(Z = A, (f(X = Z, a:X)).snd:£{r+-(/(^ = Z, a:X)).Fst}) 

where a : A, since the open (X = Z, a : X) as . . . must take place inside the (Z = A, . . . : 
. . .), hence violating the scoping rule for open. 

Moreover, the translation above can still be applied to terms in normal form satisfying 
condition (C), and, in that case, still leads to well-typed terms of the open calculus, since 
for terms in normal form, type equivalence is again syntactic equality. 

5 Conclusion 

We have described two notations for type abstraction, one coming from logic, the other 
from programming, and investigated their relationships. This work contributes to the 
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formal foundation of the notion of abstraction found in programming. It also suggests 
some interesting extensions, as we shall see now. 

The grammar of a calculus with the dot notation may ensure that condition (C) 
always holds. Let p range over the class of terms allowed to appear before a .Fst or a 
.snd construct; 

a :: = . . . | p. snd | . . . 
A ... | p.Fst | . . . 

If p cannot contain any type variable at all, then condition (C) will certainly hold. This 
is the case, of course, for the simple dot calculus of section 2 (p ::= x). 

This is also the case for the extension to "paths" mentioned at the beginning of the 
previous section (p ::— x | p. snd). This notion of paths gives a convenient way to deal with 
nested abstractions, which is much more natural than, for instance, the nested modules of 
Modula-2 [16]. Such a multi-level stratification (as opposed to the usual "flat" structure of 
programs considered as a set of modules) seems necessary for very large software systems. 

Condition (C) even suggests other extensions, for instance: 

p, p' ::— x | p. snd | p(p') 

This would be convenient for dealing with parameterized abstractions. For example, 
assuming we extend the system with first-order dependent types V(x : A)B, we could 
write: 

type Disc(cpx : Complex) = 

3X. make : cpx. Fst — » Real — ► X, ... 

val disc : V(cpx: Complex) Disc(cpx) = 
A cpx : Complex. 

{ X = cpx. Fst x Real 
make = Xorig : Complex. Xradius : Real, (orig, radius) 

• ••) 

Here, disc(cpx) would be a package implementing abstract discs of given origin and 
radius, depending on a given implementation cpx of Complex. For example, disc(polar- 
.complex) and disc( cartesian. complex) would provide different implementations of the 
parametric disc abstraction. Two instances of disc(polar .complex) would be recognized 
to refer to the same abstraction, according to the translation based on condition (C), and 
could hence interact freely. 

In conclusion, we can define more and more expressive calculi based on the dot nota- 
tion. The most expressive ones, only sketched in this section, should be able to deal with 
complex dependencies between first-class parametric abstractions. Our calculi are closer 
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to actual programming languages than are calculi based on logical notation, but enjoy all 
the same interesting properties. 
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